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STATUS OF AMENDMENTS 

No claims were amended in Appellants' response to the Final Office Action mailed 
November 23, 2010. 



SUMMARY OF CLAIMED SUBJECT MATTER 

CLAIM 1 - INDEPENDENT 

The present invention provides a method for displaying a list of service requests from 
multiple service request systems on a single display (e.g., 12, FIG. 1). See, e.g., specification, 
page 4, lines 3-5. 

A computer processor receives a service inquiry from a browser (e.g., 51, FIG. 3) to 
which a technician is interfaced at a computer (e.g., 10, FIG. 1; 23, 24, FIG. 2) comprising the 
browser, said computer processor being comprised by a gateway manager (e.g., 49, FIG. 3), said 
service inquiry requesting a list of services assigned to the technician for being performed by the 
technician. See, e.g., step 60, FIG. 4; specification, page 12, lines 6-8. 

In response to said receiving the service inquiry, said processor formulates and sends a 
service request status message to a plurality of service ticketing systems (e.g., 41-44, FIG. 3), 
said service request status message requesting service tickets specifying the services assigned to 
the technician. See, e.g., step 61, FIG. 4; specification, page 12, lines 8-14. 

After said sending the service request status message, said processor receives the service 
tickets from the service ticketing systems, each service ticket specifying a different service of the 
services assigned to the technician. See, e.g., step 62, FIG. 4; specification, page 12, lines 14-17. 

Said processor merges the received service tickets into a response list of tickets. See step, 
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e.g., 63, FIG. 4; specification, page 17, lines 16-18. 

Said processor sorts the tickets in the response list by sort parameters to generate multiple 
sorted ticket request lists. See, e.g., steps 64-65, FIG. 4; specification, page 17, lines 18-27. 

Said processor stores the multiple sorted ticket request lists in a cache memory at the 
gateway manager for subsequent display to the technician of a sorted ticket request list of the 
multiple sorted ticket request lists, wherein the multiple sorted ticket request lists are 
concurrently stored in the cache memoiy. See, e.g., steps 66-67, FIG. 4; specification, page 17, 
lines 27-29. 

CLAIM 35 - INDEPENDENT 

The present invention provides a computer program product, comprising a computer 
readable storage medium (e.g., 25, FIG. 2) having a computer readable instructions stored 
therein, said instructions configured to be executed by a computer processor of a gateway 
manager (e.g., 49, FIG. 3) to implement a method for displaying a list of service requests from 
multiple service request systems on a single display (e.g., 12, FIG. 1). See, e.g., specification, 
page 14, lines 3-9; page 8, lines 6-10; page, 4, lines 3-5. 

A service inquiry is received from a browser (e.g., 51, FIG. 3) to which a technician is 
interfaced at a computer (e.g., 10, FIG. 1; 23, 24, FIG. 2) comprising the browser, said service 
inquiry requesting a list of services assigned to the technician for being performed by the 
technician. See, e.g., step 60, FIG. 4; specification, page 12, lines 6-8. 

In response to said receiving the service inquiry, a service request status message is 
formulated and sent to a plurality of service ticketing systems (e.g., 41-44, FIG. 3), said service 

S/N: 10/076,362 3 



request status message requesting service tickets specifying the services assigned to the 
technician. See, e.g., step 61, FIG. 4; specification, page 12, lines 8-14. 

After said sending the service request status message, the service tickets are received 
from the service ticketing systems, each service ticket specifying a different service of the 
services assigned to the technician. See, e.g., step 62, FIG. 4; specification, page 12, lines 14-17. 

The received service tickets are merged into a response list of tickets. See, e.g., step 63, 
FIG. 4; specification, page 17, lines 16-18. 

The tickets in the response list are sorted by sort parameters to generate multiple sorted 
ticket request lists. See, e.g., steps 64-65, FIG. 4; specification, page 17, lines 18-27. 

The multiple sorted ticket request lists are stored in a cache memory at the gateway 
manager for subsequent display to the technician of a sorted ticket request list of the multiple 
sorted ticket request lists, wherein the multiple sorted ticket request lists are concurrently stored 
in the cache memory. See, e.g., steps 66-67, FIG. 4; specification, page 17, lines 27-29. 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 1-3, 34-37 and 45 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of 
Toyouchi et al. (U.S. Patent 6,847,988 B2) (hereafter Toyouchi). 

2. Claims 9, 10, 38 and 39 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of 
Toyouchi et al. (U.S. Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Bergeron et 
al. (U.S. Patent 4,922,514) (hereafter Bergeron). 

3. Claims 29 and 40 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of Toyouchi et al. (U.S. 
Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Northcutt et al. (U.S. Patent 
Publication No. 2003/0126001) (hereafter Northcutt). 

4. Claims 30 and 41 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of Toyouchi et al. (U.S. 
Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Northcutt et al. (U.S. Patent 
Publication No. 2003/0126001) (hereafter Northcutt). 



5. Claims 31, 32, 33, 42, 43 and 44 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of 
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Toyouchi et al. (U.S. Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Smith et al. 
(U.S. Patent 7,013,469 B2). 
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ARGUMENT 



GROUND OF REJECTION 1 

Claims 1-3, 34-37 and 45 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of 
Toyouchi et al. (U.S. Patent 6,847,988 B2) (hereafter Toyouchi). 

Claims 1 and 35 

Appellants respectfully contend that claims 1 and 35 are not unpatentable over Kinser in 
view of Toyouchi, because Kinser in view of Toyouchi does not teach or suggest each and every 
feature of claims 1 and 35. 

A first example of why claims 1 and 35 are not unpatentable over Kinser in view of 
Toyouchi is that Kinser in view of Toyouchi does not teach or suggest the feature: "a computer 
processor receiving a service inquiry from a browser to which a technician is interfaced at a 
computer comprising the browser, said computer processor being comprised by a gateway 
manager, said service inquiry requesting a list of services assigned to the technician for being 
performed by the technician" (emphasis added). 

The Examiner argues (office action, page 8): "Kinser does not explicitly disclose the 
following limitation, however, ... Toyouchi a computer processor receiving a service inquiry 
from a browser to which a technician is interfaced at a computer Comprising the browser, said 
computer processor being comprised by a gateway manager, said service inquiry requesting a list 
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of services assigned to the technician for being performed by the technician (see; col. 11, lines 
25-45), col. 38, line (54) - col. 39, line (17), col. 42, lines (4-6, and lines (55-67) of Toyouchi 
teaches a computer processor being used with a browser to manage service requests in the form 
of a plurality of requests (i.e. services) through a gateway stored in a table (i.e. list))." 

In response, Appellants respectfully contend that the preceding citations to Toyouchi (col. 
11, lines 25-45; col. 38, line 54 - col. 39, line 17; col. 42, lines 4-6; and col. 42, lines 55-67) do 
not disclose the existence of a technician interfaced at a browser such that a computer processor 
receives from the browser a list of services assigned to the technician for being performed by the 
technician. 

Toyouchi, col. 1 1, lines 25-45 discusses a table depicted in Toyouchi, FIG. 3, said table 
including values of attributes relating to services requested by users. Toyouchi, col. 11, lines 
25-45 is totally silent as to a technician interfaced at a browser such that a computer processor 
receives from the browser a list of services assigned to the technician for being performed by the 
technician. 

Toyouchi, col. 38, line 54 - col. 39, line 17 describes a connection between, and a 
message transmitted between, an information acquiring computer and a service providing 
computer. Toyouchi, col. 38, line 54 - col. 39, line 17 is totally silent as to a technician 
interfaced at a browser such that a computer processor receives from the browser a list of 
services assigned to the technician for being performed by the technician. 

Toyouchi, col. 42, lines 4-6 recites: "the request may be broadcasted to all of the service 
providing processors". Toyouchi, col. 42, lines 4-6 is totally silent as to a technician interfaced at 
a browser such that a computer processor receives from the browser a list of services assigned to 
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the technician for being performed by the technician. 

Toyouchi, col. 42, lines 55-67 recites: "As an example of the information acquiring 
computer 310, there are an exclusive use terminal, a personal computer, a workstation, a 
multimedia kiosku a personal portable terminal (PDA) and so on. As an example of the 
information providing 10 computer 21, there are a database server, a World Wide Web (WWW) 
server, an FTP server, a WAIS server, a Gopher server and a so on." Toyouchi, col. 42, lines 55- 
67 is totally silent as to a technician interfaced at a browser such that a computer processor 
receives from the browser a list of services assigned to the technician for being performed by the 
technician. 

In "Response to Arguments", the Examiner further argues (office action, page 4): 
"Additionally while Toyouchi states a technician pulls the information together and then Kinser 
takes this information and distributes it to technicians there is no indication that the technician of 
Toyouchi who inputs the information could not then assign himself/herself one of some the 
trouble tickets (i.e. service requests)". 

In response, Appellants assert that Toyouchi does not disclose that the person who inputs 
the information assigns, or could assign, himself/herself one of some the trouble tickets. 

The Examiner's argument that "there is no indication that the technician of Toyouchi who 
inputs the information could not then assign himself/herself one of some the trouble tickets (i.e. 
service requests)" reflects the Examiner's speculation and not what Toyouchi actually discloses, 
and is accordingly indicative of the Examiner's failure to establish a prima facie case of 
obviousness in relation to claims 1 and 35. 

Therefore, Kinser in view of Toyouchi does not disclose the preceding feature of claims 1 
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and 35. 



A second example of why claims 1 and 35 are not unpatentable over Kinser in view of 
Toyouchi is that Kinser in view of Toyouchi does not teach or suggest the feature: 

"in response to said receiving the service inquiry, said processor formulating and sending 
a service request status message to a plurality of service ticketing systems, said service request 
status message requesting service tickets specifying the services assigned to the technician; 

after said sending the service request status message, said processor receiving the service 
tickets from the service ticketing systems, each service ticket specifying a different service of the 
services assigned to the technician". 

The Examiner argues (office action, page 7): "Kinser teaches ... 

in response to said receiving the service inquiry, said processor formulating and sending a 
service request status message to a plurality of service ticketing systems (see; col. 55, lines 
(46-61) of Kinser teaches batch processing (i.e. formulating) and submitting the open service 
requests to a system for dispatch to multiple systems. 

said service request status message requesting service tickets specifying the services 
assigned to the technician from the service manager (see; col. 55, lines (58-61) of Kinser teaches 
assigning trouble tickets assigned to specific technicians). 

after said sending the service request status message, said processor receiving the service 
tickets from the service ticketing systems, each service ticket specifying a different service of the 
services assigned to the technician (see; col. 55, line (56-61) of Kinser teaches the garages 
receiving the service tickets for the specific technicians and the details of the work)." 
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In response, Appellants note that Kinser, col. 55, lines 46-61discloses that WFA/DO 
receives the trouble tickets created by a process initiated by the Service Analysis (SA). 
Appellants assume that the trouble tickets represent the claimed service tickets. 

However, Kinser, col. 55, lines 46-61 does not disclose sending (to a plurality of service 
ticketing systems) a service request status message requesting service tickets specifying the 
services assigned to the technician as claimed. 

In "Response to Arguments", however, the Examiner argues (office action, page 2): "In 
the previously sited area of Kinser col. 55, lines (46-61) Kinser teaches that the WFA/DO is a 
relied upon for dispatch of the trouble tickets (i.e. service requests) to the different technicians" 
(emphasis added). 

Thus, the Examiner is alleging that the service request status message is the service 
tickets (i.e., trouble tickets). Since the trouble tickets are disclosed in Kinser, col. 55, lines 46- 
61, the Examiner's assumption that the service request status message is the trouble tickets 
allegedly supports the Examiner's argument that the service request status message is disclosed 
in Kinser, col. 55, lines 46-61. 

However, if the service request status message is the service tickets, then the limitation of 
"said service request status message requesting service tickets" equates to "said service tickets 
requesting service tickets" which is an inference that does not make any sense and which Kinser 
does not disclose. 

In addition, if the service request status message is the service tickets, then the 
combination of the limitations of "said processor formulating and sending a service request status 
message to a plurality of service ticketing systems" and "after said sending the service request 

S/N: 10/076,362 11 



status message, said processor receiving the service tickets from the service ticketing systems" 
requires the processor to send the service tickets to the plurality of service ticketing systems and 
subsequently receive the service tickets back from the plurality of service ticketing systems, 
which is an inference that does not make sense and which Kinser does not disclose. 

Thus, EITHER (i) Kinser, col. 55, lines 46-61 does not disclose sending the service 
request status message OR (ii) Kinser, col. 55, lines 46-61 allegedly discloses sending the service 
request status message under the assumption that the service request status message is the service 
tickets which leads to inferences that do not make sense and which are not disclosed in Kinser as 
discussed supra. 

In addition, Kinser, col. 55, lines 46-61 does not disclose the plurality of service ticketing 
systems to which the service request status message must be sent. 

In addition, Appellants note that the Examiner's arguments refer to multiple technicians 
which violates what is being claimed. All language in claims 1 and 35 pertains to one and only 
one technician who is assigned to perform a list of services and who is interfaced at a computer 
comprising the browser from which a service inquiry is sent. 

In "Response to Arguments", the Examiner argues (office action, pages 3-4): "the 
examiner points out that the claim language does not say that the technicians have to be the same 
individual, nor does it state that there is in fact only one technician." 

In response, Appellants assert that claims 1 and 35 refer to "a technician" and "the 
technician" and do not mention "technicians". 

In "Response to Arguments", the Examiner further argues (office action, page 4): 
"Additionally while Toyouchi states a technician pulls the information together and then Kinser 
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takes this information and distributes it to technicians there is no indication that the technician of 
Toyouchi who inputs the information could not then assign himself/herself one of some the 
trouble tickets (i.e. service requests) making it only one individual as alleged by the applicant." 

In response, Appellants assert that Toyouchi does not disclose that the person who inputs 
the information assigns, or could assign, himself/herself one of some the trouble tickets. 

The Examiner's argument that "there is no indication that the technician of Toyouchi who 
inputs the information could not then assign himself/herself one of some the trouble tickets (i.e. 
service requests)" reflects the Examiner's speculation and not what Toyouchi actually discloses, 
and is accordingly indicative of the Examiner's failure to establish a prima facie case of 
obviousness in relation to claims 1 and 35. 

Therefore, Kinser in view of Toyouchi does not disclose the preceding feature of claims 1 

and 35. 

A third example of why claims 1 and 35 are not unpatentable over Kinser in view of 
Toyouchi is that Kinser in view of Toyouchi does not teach or suggest the feature: "said 
processor sorting the tickets in the response list by sort parameters to generate multiple sorted 
ticket request lists". 

The Examiner argues (office action, page 8): "Kinser teaches ... said processor sorting the 
tickets in the response list by sort parameters to generate multiple sorted ticket request lists (see; 
col. 28, lines (16-18), col. 50, line (65) - col. 51, line (14), col. 55, lines (57-61) of Kinser teaches 
the capability of sorting service based on the priority of the service request and creating multiple 
tickets to different technicians based on what is needed to be completed an when and all this will 
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show up on the dispatch report (i.e. list)." 

In response, Appellants note that, of the citations to Kinser in the preceding argument by 
the Examiner, the only citation to Kinser mentioning sorting is in Kinser, col. 28, lines 16-18 
which recites: "access and print entries, sorted by wire center and start date, for a set of wire 
centers defined by the Maintenance Center user list". 

However, the preceding feature of claims 1 and 35 recites "sorting the tickets in the 
response list by sort parameters to generate multiple sorted ticket request lists" which the 
preceding quote from Kinser, col. 28, lines 16-18 does not disclose. The preceding quote from 
Kinser, col. 28, lines 16-18 merely discloses sorting access and print entries, which is not specific 
to ticket request lists and is not a disclosure of generating multiple sorted lists. 

In "Response to Arguments", the Examiner argues (office action, page 5): "These trouble 
tickets are open requests for work and contain the list of all required actions. Additionally, there 
is a sorting process that takes place based on priority, which will impact the amount of groups 
formed (see; col. 55, lines (54-55) of Kinser)." 

In response, Appellants note that Kinser, col. 55, lines 54-56 recite: "Knowing the 
number of groups allowed, the process reads the priorities of all "suggested" trouble groups and 
creates "open" trouble tickets." 

Appellants assert that the preceding quote from Kinser, col. 55, lines 54-56 discloses 
reading the priorities and does not disclose sorting on the priorities. A disclosure of performing 
services based on how the services are prioritized is not a disclosure of sorting the priorities and 
is not a disclosure of generating a sorted list of the services based on their priorities. Performing 
the services based on their priorities requires only knowing what their priorities are, and does not 
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require sorting the priorities to generate a sorted list. 

Therefore, Kinser in view of Toyouchi does not disclose the preceding feature of claims 1 

and 35. 

A fourth example of why claims 1 and 35 are not unpatentable over Kinser in view of 
Toyouchi is that Kinser in view of Toyouchi does not teach or suggest the feature: "said 
processor storing the multiple sorted ticket request lists in a cache memory at the gateway 
manager for subsequent display to the technician of a sorted ticket request list of the multiple 
sorted ticket request lists, wherein the multiple sorted ticket request lists are concurrently stored 
in the cache memory". 

The Examiner argues (office action, page 8): "Kinser teaches ... said processor storing the 
multiple sorted ticket request lists in a cache memory at the gateway manager for subsequent 
display to the technician of a sorted ticket request list of the multiple sorted ticket request lists, 
wherein the multiple sorted ticket request lists are concurrently stored in the cache memory (see; 
col. 43, lines (60-64), col. 47, lines (28-37), col. 55, lines (52-61), and col. 57, lines (19-26) of 
Kinser teaches a processor that stores multiple trouble tickets and the dispatch report (i.e. request 
lists) in memory that can be viewed in a display and additionally uses a gateway to distribute the 
trouble tickets to the technicians)." 

In response, Appellants note that Kinser, col. 43, lines 60-64 recites: "FIG. 24 is a block 
diagram of a proactive service management process. In FIG. 24, Caseworker 308 is used for 
coordinating trouble reports received from MLT 314 (via standard interface Gateway 348)", 
which does not disclose concurrently storing the multiple sorted ticket request lists in a cache 
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memory at the gateway manager. 

In further response, Appellants note that Kinser, col. 47, lines 28-37 recites: "Once ALIT 
is completed for a given wire center (all ALIT scheduled testing must be complete if the wire 
center has multiple switches), SA determines if the individual server has enough memory and 
resources to begin another SA process. This determination must be done due to the wire center 
data distribution. Each server covers data for multiple, preassigned wire centers, and due to the 
processing requirements of SA, only a certain number of wire center SA processes (based on 
wire center size) can realistically run on one server at a time", which does not disclose 
concurrently storing the multiple sorted ticket request lists in a cache memory at the gateway 
manager. 

In further response, Appellants note that Kinser, col. 55, lines 52-61 recites: "Therefore, 
based on priorities, different numbers of trouble ticket groups will be opened. Knowing the 
number of groups allowed, the process reads the priorities of all "suggested" trouble groups and 
creates "open" trouble tickets. This process then submits these open trouble ticket groups to 
WFA/DO for dispatch... This process also sends the technician's dispatch report, provided by the 
Post-MLT SA process listing all the area detail for their specific trouble group, to the local 
garage printer", which does not disclose concurrently storing the multiple sorted ticket request 
lists in a cache memory at the gateway manager. 

In further response, Appellants note that Kinser, col. 57, lines 19-26 recites: "Service 
Analysis can be run by a batch process, or asynchronous processing to respond to customer calls 
in real-time. Caseworkers access Service Analysis on a real-time basis. If the need for an outside 
dispatch is established, the system will read all associated proactive trouble groups to append to 
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the new customer call. In addition, related closed trouble tickets and defective pairs will be 
grouped as well to display for the technician", which does not disclose concurrently storing the 
multiple sorted ticket request lists in a cache memory at the gateway manager. 

Appellants assert that the preceding quotes to Kinser do not mention anything about a 
sorted ticket request list and therefore do not disclose "storing the multiple sorted ticket request 
lists in a cache memory wherein the multiple sorted ticket request lists are concurrently 
stored in the cache memory" (emphasis added). 

Appellants assert that the preceding quotes to Kinser do not mention anything about 
cache memory and therefore do not disclose "storing the multiple sorted ticket request lists in a 
cache memory wherein the multiple sorted ticket request lists are concurrently stored in the 
cache memory" (emphasis added). 

Appellants assert that there is no disclosure in Kinser of using cache memory for any 
purpose. In fact, there is not even any mention of cache memory in Kinser. 

Therefore, Kinser in view of Toyouchi does not disclose the preceding feature of claims 1 

and 35. 

In addition, the Examiner has not identified, with specificity and clarity, exactly what 
entities in Kinser and Toyouchi represents the following claimed entities: "service inquiry", 
"service request status message", "service tickets", and "plurality of ticketing systems". 



Based on the preceding arguments, Appellants respectfully maintain that claims 1 and 35 
are not unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), and that claims 1 
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and 35 are in condition for allowance. 



Claims 2 and 36 

Since claims 2 and 36 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), 
Appellants maintain that 2 and 36 are likewise not unpatentable over Kinser in view of Toyouchi 
under 35 U.S.C. § 103(a). 

In addition with respect to claims 2 and 36, Kinser in view of Toyouchi does not disclose 
the feature: "before said sending the service request status message, said processor converting the 
service status request message to a format that is specific for each service ticketing system". 

The Examiner argues (office action, page 9): "Referring to Claim 2, ... Kinser further 
disclose the following limitation.... before said sending the service request status message, said 
processor converting the service status request message to a format that is specific for each 
service ticketing system (see; col. 46, lines (1-19), and col. 58, lines (48-50) of Kinser teaches the 
service requests are grouped together in proactive and reactive along with a common service 
order processor that ensures the format is translated properly)." 

In response, Appellants assert that Kinser, col. 46, lines 1-19 discusses grouping troubles 
by geographical area, using historical switch surveillance information, and grouping proactive or 
reactive troubles. Appellants assert that the preceding quote from Kinser, col. 46, lines 1-19 does 
not disclose "converting the service status request message to a format that is specific for each 
service ticketing system". 

In further response, Appellants note that Kinser, col. 58, lines 48-50 recites: "CSOP— 
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Common Service Order Processor— Translates service request from SSNS into service order 
format and reverse." Appellants assert that the preceding quote from Kinser, col. 58, lines 48-50 
does not disclose "converting the service status request message to a format that is specific for 
each service ticketing system". 

First, the "service request" referred to in Kinser, col. 58, lines 48-50 does not satisfy the 
requirement of the claimed limitation of "requesting service tickets specifying the services 
assigned to the technician" (see claims 1 and 35 from which claims 2 and 36 respectively 
depend). 

Second, although the preceding quote in Kinser, col. 58, lines 48-50 discloses converting 
to a "service order format", the preceding quote in Kinser, col. 58, lines 48-50 does not disclose 
converting to a format that is specific for each service ticketing system. In fact, Kinser does not 
even disclose the claimed plurality of ticketing systems. 

Accordingly, claims 2 and 36 are not unpatentable over Kinser in view of Toyouchi under 
35 U.S.C. §103(a). 

Claims 3 and 37 

Since claims 3 and 37 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), 
Appellants maintain that 3 and 37 are likewise not unpatentable over Kinser in view of Toyouchi 
under 35 U.S.C. § 103(a). 



Claims 34 and 45 
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Since claims 34 and 45 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), 
Appellants maintain that 34 and 45 are likewise not unpatentable over Kinser in view of 
Toyouchi under 35 U.S.C. § 103(a). 

In addition with respect to claims 34 and 45, Kinser in view of Toyouchi does not 
disclose the feature: "displaying to the technician the sorted ticket request list by displaying 
sequential segments of tickets in the sorted ticket request list". 

The Examiner argues (office action, page 10): "Referring to Claim 34, Kinser in view of 
Toyouchi teach the method of claim 1, Kinser further disclose the following limitation.... 
displaying to the technician the sorted ticket request list by displaying sequential segments of 
tickets in the sorted ticket request list (see; col. 28, lines (16-18), col. 50, line(65) - col. 51, line 
(14) col. 55, lines (58-61) of Kinser teaches displaying a report with the service that needs to be 
performed listed based on how they were prioritized (i.e. sorted segments) before being sent)." 

hi response, Appellants assert that the "report" referred to in the preceding argument by 
the Examiner is not "the sorted request list" that results from sorting the tickets. As explained 
supra in conjunction with claims 1 and 35, Kinser discloses reading the priorities but does not 
disclose sorting the priorities. A disclosure of performing services based on how the services are 
prioritized is not a disclosure of sorting the priorities and is not a disclosure of generating a 
sorted list of the services based on their priorities. Performing the services based on their 
priorities requires only knowing what their priorities are, and does not require sorting the 
priorities. 

Accordingly, claims 34 and 45 are not unpatentable over Kinser in view of Toyouchi 
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under 35 U.S.C. § 103(a). 
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GROUND OF REJECTION 2 

Claims 9, 10, 38 and 39 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of 
Toyouchi et al. (U.S. Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Bergeron et 
al. (U.S. Patent 4,922,514) (hereafter Bergeron). 

Claims 9 and 38 

Since claims 9 and 38 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. §103(a), 
Appellants maintain that claims 9 and 38 are not unpatentable over Kinser in view of Toyouchi, 
in further view of Bergeron under 35 U.S.C. § 103(a). 

In addition with respect to claims 9 and 38, Kinser in view of Toyouchi, in further view 
of Bergeron does not disclose the feature: "determining an elapsed time since a last inquiry by 
the technician". 

The Examiner argues (office action, page 12): "Kinser and Toyouchi do not explicitly 
disclose the following limitation, however.... Bergeron teaches said processor determining an 
elapsed time since a last inquiry by a the technician (see; col. 4, lines (1-20) of Bergeron teaches 
a processor that keeps track of service engineers (i.e. technician) based on a event or time driven 
schedule and how it is accessed with an input/output device (i.e. inquiry))." 

In response, Appellants respectfully contend that there is no disclosure in Bergeron, col. 
4, lines 1-20 of an elapsed time. Keeping track of service engineers (i.e. technician) based on an 
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event or time driven schedule requires an awareness of what the current time is in relation to the 
schedule and does not require keeping track of an elapsed time. 

In further response, Appellants respectfully contend that there is no mention in Bergeron, 
col. 4, lines 1-20 of "a last inquiry by the technician". Therefore, Bergeron, col. 4, lines 1-20 
does not disclose "determining an elapsed time since a last inquiry by the technician. 

Accordingly, claims 9 and 38 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Bergeron. 

In addition with respect to claims 9 and 38. Kinser in view of Toyouchi. in further view 
of Bergeron does not disclose the feature: "resetting the sorted ticket lists in the cache after a 
predetermined time period has expired". 

The Examiner argues (office action, page 11): "Referring to Claim 9, Kinser in view of 
Toyouchi teach the method of claim 1, Kinser further disclose the following limitation... said 
processor resetting the sorted ticket lists in the cache after a predetermined time period (see; col. 
29, lines (39-43), col. 47, lines (28-37), and col. 55, lines (52-61) of Kinser teaches a processor 
and memory that takes the sorted data and tries to maximize the efficiency of the work being 
completed therefore the dispatch report is sent to the technician with current open items to 
complete)." 

In response, Appellants respectfully contend that the preceding argument by the Examiner 
does not address the preceding feature of claims 9 and 38, because the preceding argument by the 
Examiner does not address: 

(i) the sorted ticket lists; 
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(ii) resetting the sorted ticket lists; 

(iii) resetting the sorted ticket lists in the cache; 

(iv) resetting the sorted ticket lists in the cache after a predetermined time period 
has expired. 

Accordingly, claims 9 and 38 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Bergeron. 

Claims 10 and 39 

Since claims 10 and 39 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. §103(a), 
Appellants maintain that claims 10 and 39 are not unpatentable over Kinser in view of 
Toyouchi, in further view of Bergeron under 35 U.S.C. § 103(a). 

In addition with respect to claims 10 and 39, Kinser in view of Toyouchi, in further view 
of Bergeron does not disclose the feature: "wherein said resetting comprises retrieving additional 
tickets for the ticketing systems". 

The Examiner argues (office action, pages 12-13): "Referring to Claim 10, Kinser in 
view of Toyouchi in further view of Baergeron teach the method of claim 9, Kinser further 
disclose the following limitation... wherein said resetting comprises retrieving additional tickets 
for the ticketing systems (see; col. 21, par. (35-42), and col. 55, lines (56-61) of Kinser teaches a 
re-prioritizing of the group of service requests and then distributing them to the correct 
technician)." 

In response, Appellants respectfully contend that the preceding argument by the Examiner 
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alleges that Kinser teaches re-prioritizing the same group of service requests and does not 
address additional tickets. Furthermore, the preceding feature of claims 10 and 39 does not 
recite retrieving additional tickets for the technician, but rather recites retrieving additional 
tickets for the ticketing systems. 

Accordingly, claims 10 and 39 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Bergeron. 
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GROUND OF REJECTION 3 

Claims 29 and 40 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of Toyouchi et al. (U.S. 
Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Northcutt et al. (U.S. Patent 
Publication No. 2003/0126001) (hereafter Northcutt). 

Since claims 29 and 40 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), 
Appellants maintain that claims 29 and 40 are not unpatentable over Kinser in view of Toyouchi, 
in further view of Northcutt under 35 U.S.C. § 103(a). 
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GROUND OF REJECTION 4 

Claims 30 and 41 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of Toyouchi et al. (U.S. 
Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Northcutt et al. (U.S. Patent 
Publication No. 2003/0126001) (hereafter Northcutt). 

Since claims 30 and 41 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. §103(a), 
Appellants maintain that claims 30 and 41 are not unpatentable over Kinser in view of Toyouchi, 
in further view of Northcutt under 35 U.S.C. § 103(a). 

In addition with respect to claims 30 and 41, Kinser in view of Toyouchi, in further view 
of Northcutt does not disclose the feature: "creating a different integer array of pointers for each 
sort parameter to index a sort order of the tickets in the response list for each sort parameter, 
wherein each pointer in each integer array points to a ticket in the response list, and rearranging 
the pointers in each integer array as the tickets are rearranged in the response list for each sort 
parameter". 

The Examiner argues (office action, page 15): "Kinser, Toyouchi and Northcutt do not 
explicitly disclose the following limitations however, ... Smith teaches creating a different 
integer array of pointers (see; col. 400, lines (33-35) of Smith teaches an integer array and ifs 
combination with pointers), and wherein each pointer in each integer array points to an item (see; 
col. 6, lines (19-29) and col. 400, lines (33-35) of Smith teaches that pointers are used to point to 
items, and that pointer are part of the integer array), and rearranging the pointers in each integer 
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array as the tickets are rearranged in the response list for each sort parameter (see; col. 6, lines 
10-14), and col. 237, lines (10-14) of Smith teaches an integer array used in sorting parameters)." 

In response, Appellants respectfully contend that claims 30 and 41 are rejected as 
allegedly unpatentable over Kinser in view of Toyouchi, in further view of Northcutt. Thus 
claims 30 and 41are not rejected over Smith (U.S. Patent 7,013,469) or in view of Smith. 
Therefore, Smith cannot be used as a prior art reference to support a rejection of claims 30 and 
31 over Kinser in view of Toyouchi, in further view of Northcutt. Accordingly, the Examiner's 
reliance on Smith is misplaced and the Examiner has not established a prima facie case of 
obviousness in relation to claims 30 and 41. 

However, Appellants next discuss Smith in order to explain why further rejecting claims 
30 and 41 over Smith would not be persuasive. 

In particular, Smith does not disclose creating a different integer array of pointers for each 
sort parameter and rearranging the pointers in each integer array as the tickets are rearranged in 
the response list for each sort parameter, at least because the Examiner's citations to Smith are 
totally silent as to sorting. 

Appellants note that Smith, col. 400, lines 33-35 recites "Initializes a new instance of the 
String class to the value indicated by a specified pointer to an array of Unicode characters" which 
is totally silent as to sorting. 

Appellants note that Smith, col. 6, lines 19-29 recites "The API 142 groups API functions 
into multiple namespaces. Namespaces essentially define a collection of classes, interfaces, 
delegates, enumerations, and structures, which are collectively called "types", that provide a 
specific set of related functionality. A class represents managed heap allocated data that has 
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reference assignment semantics. A delegate is an object oriented function pointer. An 
enumeration is a special kind of value type that represents named constants. A structure 
represents static allocated data that has value assignment semantics. An interface defines a 
contract that other types can implement", which is totally silent as to sorting. 

Appellants note that Smith, col. 6, lines 8-14 recites "The operating system 146(1) 
provides conventional functions, such as file management, notification, event handling, user 
interfaces (e.g., windowing, menus, dialogs, etc.), security, authentication, verification, processes 
and threads, memory management, and so on. The object model services 146(2) provide 
interfacing with other objects to perform various tasks", which is totally silent as to sorting. 

Appellants note that Smith, col. 237, lines 10-14 recites "Converts the value of a 
specified instance of Decimal to its equivalent binary representation, and returns that 
representation in an array of 32-bit signed integers. Return Value: A 32-bit integer array with 
four elements that contain the binary representation of d", which is totally silent as to sorting. 

Accordingly, claims 30 and 41 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Northcutt. 
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GROUND OF REJECTION 5 

Claims 31, 32, 33, 42, 43 and 44 stand rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over Kinser, Jr. et al. (U.S. Patent 5,687,212) (hereafter Kinser) in view of 
Toyouchi et al. (U.S. Patent 6,847,988 B2) (hereafter Toyouchi), in further view of Smith et al. 
(U.S. Patent 7,013,469 B2). 

Claims 31 and 42 

Since claims 31 and 42 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. §103(a), 
Appellants maintain that claims 31 and 42 are not unpatentable over Kinser in view of Toyouchi, 
in further view of Smith under 35 U.S.C. §103(a). 

In addition with respect to claims 31 and 42, Kinser in view of Toyouchi, in further view 
of Smith does not disclose the feature: "wherein the sort parameters consist of a first sort 
parameter and a second sort parameter" (emphasis added). 

The Examiner argues (office action, page 16): Referring to Claim 31, ... Smith teaches 
wherein the sort parameters consist of a first sort parameter and a second sort parameter (see; col. 
737, lines (9-11) of Smith teaches two sort parameters)". 

In response, Appellants note that Smith, col. 737, lines 9-11 recite "Compares two sort 
keys. Return Value: Value Condition Zero The two sort keys are equal. The first sort key to 
compare. The second sort key to compare", which does not disclose the closed-ended limitation 
of "the sort parameters consist of a first sort parameter and a second sort parameter". 
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Accordingly, claims 31 and 42 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Smith. 

In addition with respect to claims 31 and 42, Kinser in view of Toyouchi, in further view 
of Smith does not disclose the feature: "wherein the multiple sorted ticket request lists consist of 
a first sorted ticket request list and a second sorted ticket request list" (emphasis added). 

The Examiner argues (office action, page 16): Referring to Claim 31, ... Smith teaches 
... wherein the multiple sorted ticket request lists consist of a first sorted ticket request list and a 
second sorted ticket request list (see; col. 75, lines (29-35) and col. 737, lines (9-11) the sorting 
of multiple of data including the ability to sort two parameters)". 

In response, Appellants note that Smith, col. 75, lines 26-35 discloses a function that sorts 
a one-dimensional array ("[JScript] public static function Sort(array: Array); Sorts the elements 
in one-dimensional System.Array objects. Description Sorts the elements in an entire one- 
dimensional System.Array using the System. IComparable interface implemented by each element 
of the System.Array. Each element of array must implement the System.IComparable interface to 
be capable of comparisons with every other element in array. The one-dimensional System.Array 
to sort."). Thus, the preceding quote from Smith, col. 75, lines 26-35 does not disclose the 
closed-ended limitation of "the multiple sorted ticket request lists consist of a first sorted ticket 
request list and a second sorted ticket request list". 

In further response, Appellants note that Smith, col. 737, lines 9-11 recite "Compares two 
sort keys. Return Value: Value Condition Zero The two sort keys are equal. The first sort key to 
compare. The second sort key to compare", which does not disclose the closed-ended limitation 
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of "the multiple sorted ticket request lists consist of a first sorted ticket request list and a second 
sorted ticket request list". 

Accordingly, claims 3 1 and 42 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Smith. 

In addition with respect to claims 3 1 and 42, Kinser in view of Toyouchi, in further view 
of Smith does not disclose the feature: "wherein said sorting comprises generating the first sorted 
ticket request list whose tickets are sorted according to the first sort parameter and generating the 
second sorted ticket request list whose tickets are sorted according to the second sort parameter". 

The Examiner argues (office action, page 16): Referring to Claim 31, ... Smith teaches 
... wherein said sorting comprises generating the first sorted ticket request list whose tickets are 
sorted according to the first sort parameter and generating the second sorted ticket request list 
whose tickets are sorted according to the second sort parameter (see; col. 75, lines (29-35) and 
col. 737, lines (9-11) the sorting of multiple of data including the ability to sort two parameters 
based on how the array is set up making for a multitude of search parameter combinations (i.e. 
first sort generating second sort))." 

In response, Appellants note that Smith, col. 75, lines 26-35 discloses a function that sorts 
a one-dimensional array ("[JScript] public static function Sort(array: Array); Sorts the elements 
in one-dimensional System. Array objects. Description Sorts the elements in an entire one- 
dimensional System.Array using the System. IComparable interface implemented by each element 
of the System.Array. Each element of array must implement the System.IComparable interface to 
be capable of comparisons with every other element in array. The one-dimensional System.Array 
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to sort.")- Thus, the preceding quote from Smith, col. 75, lines 26-35 does not disclose 
"generating the first sorted ticket request list whose tickets are sorted according to the first sort 
parameter and generating the second sorted ticket request list whose tickets are sorted according 
to the second sort parameter". 

In further response, Appellants note that Smith, col. 737, lines 9-11 recite "Compares two 
sort keys. Return Value: Value Condition Zero The two sort keys are equal. The first sort key to 
compare. The second sort key to compare", which does not disclose "generating the first sorted 
ticket request list whose tickets are sorted according to the first sort parameter and generating the 
second sorted ticket request list whose tickets are sorted according to the second sort parameter", 
which does not disclose "generating the first sorted ticket request list whose tickets are sorted 
according to the first sort parameter and generating the second sorted ticket request list whose 
tickets are sorted according to the second sort parameter". 

Accordingly, claims 31 and 42 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Smith. 

Claims 32 and 43 

Since claims 32 and 43 respectively depend from claims 1 and 35 which Appellants have 
argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), 
Appellants maintain that claims 32 and 43 are not unpatentable over Kinser in view of Toyouchi, 
in further view of Smith under 35 U.S.C. § 103(a). 

In addition with respect to claims 32 and 43, Kinser in view of Toyouchi, in further view 
of Smith does not disclose the feature: "wherein the first sort parameter consists of ticket request 
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location, and wherein the second sort parameter consists of type of service requested". 

The Examiner argues (office action, page 17): "Referring to Claim 32, ... Smith teaches 
wherein the first sort parameter, and wherein the second sort parameter(see; col. 737, lines (9-11) 
of Smith teaches two sort parameters), however Smith does not explicitly disclose that the first 
sort parameter consists of ticket request location and the second sort parameter consists of type of 
service requested, The difference between the reference (Smith, sorting method using 
parameters) and claim 32 (sorting using specific defined parameters) relates only to the intended 
use of the invention (i.e., to perform tracking a sorting method). A recitation of the intended use 
of the claimed invention must result in a structural difference between the claimed invention and 
the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior 
art structure is capable of performing the intended use, then it meets the claim." 

In response, Appellants respectfully contend that the Examiner incorrectly argues that the 
preceding feature of claims 32 and 43 is an intended use. Appellants assert that claims 32 and 43 
claim the active method step of sorting the tickets using the first and second sort parameters of 
ticket request location and type of service requested, respectively. Thus, the preceding feature of 
claims 32 and 43 is not an intended use and is not disclosed by Kinser in view of Toyouchi in 
further view of Smith. 

Accordingly, claims 32 and 43 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Smith. 



Claims 33 and 44 

Since claims 33 and 44 respectively depend from claims 1 and 35 which Appellants have 
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argued supra to not be unpatentable over Kinser in view of Toyouchi under 35 U.S.C. § 103(a), 
Appellants maintain that claims 33 and 44 are not unpatentable over Kinser in view of Toyouchi, 
in further view of Smith under 35 U.S.C. § 103(a). 

In addition with respect to claims 33 and 44, Kinser in view of Toyouchi, in further view 
of Smith does not disclose the feature: "wherein the first sort parameter consists of ticket 
submission date, and wherein the second sort parameter consists of severity of problem to which 
service is directed". 

The Examiner argues (office action, page 18): "Referring to Claim 33, Kinser in view of 
Toyouchi in further view of Smith teach the method of claim 31, Kinser in further disclose the 
following limitation... wherein the first sort parameter consists of ticket submission date, and 
wherein the second sort parameter consists of severity of problem to which service is directed 
(see; col. 45, line (19, and col. 49, line (5-8) of Kiner teaches that two possible parameters that 
can be used for sorting are date and severity of the problem)." 

In response, Appellants note that Kinser, col. 4, line 19 recites "Trouble type and severity 
relationships" which is totally unrelated to sorting. 

In further response, Appellants note that Kinser, col. 49, lines 5-8 recites "Also, the 
defective pair information (i.e., date and failure type) and spare pair count for each cable pair 
range will be obtained for use in the trouble grouping and prioritization processes, respectively" 
which is totally unrelated to sorting. 

Accordingly, claims 33 and 44 are not unpatentable over Kinser in view of Toyouchi, in 
further view of Smith. 
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SUMMARY 

In summary, Appellants respectfully request reversal of the November 23, 2010 Office 
Action rejection of claims 1-3, 9, 10, and 29-45. 



Date: April 25,2011 
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Latham, New York 12110 
Telephone (518) 220-1850 
Facsimile (518) 220-1857 
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/ Jack P. Friedman / 
Jack P. Friedman 
Registration No. 44,688 



S/N: 10/076,362 



36 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Applicant(s): Druyan et al. 



Group Art Unit: 3623 / Conf. # 1508 



Application No.: 10/076,362 



Examiner: Swartz, Stephen S. 



Filing Date: 02/14/2002 



Docket No.: AUS920011019US1 



Title: METHOD AND SYSTEM FOR MANAGING SERVICE REQUESTS ACROSS 
MULTIPLE SYSTEMS 



Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



1 . A method for displaying a list of service requests from multiple service request systems on a 
single display, said method comprising: 

a computer processor receiving a service inquiry from a browser to which a technician is 
interfaced at a computer comprising the browser, said computer processor being comprised by a 
gateway manager, said service inquiry requesting a list of services assigned to the technician for 
being performed by the technician; 

in response to said receiving the service inquiry, said processor formulating and sending a 
service request status message to a plurality of service ticketing systems, said service request 
status message requesting service tickets specifying the services assigned to the technician; 

after said sending the service request status message, said processor receiving the service 
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tickets from the service ticketing systems, each service ticket specifying a different service of the 
services assigned to the technician; 

said processor merging the received service tickets into a response list of tickets; 

said processor sorting the tickets in the response list by sort parameters to generate 
multiple sorted ticket request lists; and 

said processor storing the multiple sorted ticket request lists in a cache memory at the 
gateway manager for subsequent display to the technician of a sorted ticket request list of the 
multiple sorted ticket request lists, wherein the multiple sorted ticket request lists are 
concurrently stored in the cache memoiy. 

2. The method of claim 1, said method further comprising: 

before said sending the service request status message, said processor converting the 
service status request message to a format that is specific for each service ticketing system. 

3. The method of claim 1, said method further comprising: 

said processor converting the received service tickets into a common format, wherein said 
merging results in the response list being in the common format. 

9. The method of claim 1, said method further comprising: 

said processor determining an elapsed time since a last inquiry by the technician; and 
said processor resetting the sorted ticket lists in the cache after a predetermined time 

period has expired. 

S/N: 10/076,362 38 



10. The method of claim 9, wherein said resetting comprises retrieving additional tickets for the 
ticketing systems. 

29. The method of claim 3, wherein the common format is an XML format. 

30. The method of claim 29, wherein said sorting comprises: 

creating a different integer array of pointers for each sort parameter to index a sort order 
of the tickets in the response list for each sort parameter, wherein each pointer in each integer 
array points to a ticket in the response list, and 

rearranging the pointers in each integer array as the tickets are rearranged in the response 
list for each sort parameter. 

31. The method of claim 1, 

wherein the sort parameters consist of a first sort parameter and a second sort parameter, 
wherein the multiple sorted ticket request lists consist of a first sorted ticket request list 

and a second sorted ticket request list, and 

wherein said sorting comprises generating the first sorted ticket request list whose tickets 

are sorted according to the first sort parameter and generating the second sorted ticket request list 

whose tickets are sorted according to the second sort parameter. 



32. The method of claim 31, wherein the first sort parameter consists of ticket request location, 
and wherein the second sort parameter consists of type of service requested. 
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33. The method of claim 31, wherein the first sort parameter consists of ticket submission date, 
and wherein the second sort parameter consists of severity of problem to which service is 
directed. 

34. The method of claim 1, said method further comprising: 

displaying to the technician the sorted ticket request list by displaying sequential 
segments of tickets in the sorted ticket request list, one segment at a time. 

35. A computer program product, comprising a computer readable storage medium having a 
computer readable instructions stored therein, said instructions configured to be executed by a 
computer processor of a gateway manager to implement a method for displaying a list of service 
requests from multiple service request systems on a single display, said method comprising: 

receiving a service inquiry from a browser to which a technician is interfaced at a 
computer comprising the browser, said service inquiry requesting a list of services assigned to 
the technician for being performed by the technician; 

in response to said receiving the service inquiry, formulating and sending a service 
request status message to a plurality of service ticketing systems, said service request status 
message requesting service tickets specifying the services assigned to the technician; 

after said sending the service request status message, receiving the service tickets from 
the service ticketing systems, each service ticket specifying a different service of the services 
assigned to the technician; 

merging the received service tickets into a response list of tickets; 
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sorting the tickets in the response list by sort parameters to generate multiple sorted ticket 
request lists; and 

storing the multiple sorted ticket request lists in a cache memory at the gateway manager 
for subsequent display to the technician of a sorted ticket request list of the multiple sorted ticket 
request lists, wherein the multiple sorted ticket request lists are concurrently stored in the cache 
memory. 

36. The computer program product of claim 35, said method further comprising: 

before said sending the service request status message, said processor converting the 
service status request message to a format that is specific for each service ticketing system. 

37. The computer program product of claim 35, said method further comprising: 

converting the received service tickets into a common format, wherein said merging 
results in the response list being in the common format. 

38. The computer program product of claim 35, said method further comprising: 

determining an elapsed time since a last inquiry by the technician; and 

resetting the sorted ticket lists in the cache after a predetermined time period has expired. 

39. The computer program product of claim 38, wherein said resetting comprises retrieving 
additional tickets for the ticketing systems. 
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40. The computer program product of claim 37, wherein the common format is an XML format. 

41. The computer program product of claim 40, wherein said sorting comprises: 

creating a different integer array of pointers for each sort parameter to index a sort order 
of the tickets in the response list for each sort parameter, wherein each pointer in each integer 
array points to a ticket in the response list, and 

rearranging the pointers in each integer array as the tickets are rearranged in the response 
list for each sort parameter. 

42. The computer program product of claim 35, 

wherein the sort parameters consist of a first sort parameter and a second sort parameter, 
wherein the multiple sorted ticket request lists consist of a first sorted ticket request list 

and a second sorted ticket request list, and 

wherein said sorting comprises generating the first sorted ticket request list whose tickets 

are sorted according to the first sort parameter and generating the second sorted ticket request list 

whose tickets are sorted according to the second sort parameter. 

43. The computer program product of claim 42, wherein the first sort parameter consists of 
ticket request location, and wherein the second sort parameter consists of type of service 
requested. 



44. The computer program product of claim 42, wherein the first sort parameter consists of 
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ticket submission date, and wherein the second sort parameter consists of severity of problem to 
which service is directed. 

45. The computer program product of claim 35, said method further comprising: 

displaying to the technician the sorted ticket request list by displaying sequential 
segments of tickets in the sorted ticket request list, one segment at a time. 
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